iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 14
0

上一章 Day 13 - 什麼是IOC控制反轉? 什麼是DI依賴注入?

今天要用Service層來示範如何實作

在專案下新增一個Service資料夾, 並在其底下新增一個Interface

MemberService.java

public interface MemberService {

    public Member saveMember(Member member);

}

然後在Service資料夾底下再新增一個impl資料夾

新增MemberServiceImpl.java

@Service
public class MemberServiceImpl implements MemberService {

    @Autowired
    private MemberRepository memberRepository;

    @Override
    public Member saveMember(Member member) {
        member.setMid(UUID.randomUUID().toString().replaceAll("-", ""));
        member.setCreateTime(new Date());
        memberRepository.save(member);
        return member;
    }

}

結構大概是這樣

https://ithelp.ithome.com.tw/upload/images/20190930/20119510u19DpOVhkT.png

修改一下我們的MemberController

@RestController
@RequestMapping("/api")
public class MemberController {

    @Autowired
    private MemberRepository memberRepository;
    @Autowired
    private MemberService memberService;

    @GetMapping("/members")
    public Collection<Member> members() {
        return memberRepository.findAll();
    }

    @GetMapping("/member/{id}")
    public ResponseEntity<?> getMember(@PathVariable Long id) {
        Optional<Member> member = memberRepository.findById(id);
        return member.map(response -> ResponseEntity.ok().body(response))
                .orElse(new ResponseEntity<>(HttpStatus.NOT_FOUND));
    }

    @PostMapping("/member")
    public ResponseEntity<Member> createMember(@Valid @RequestBody Member member) throws Exception {
        Member result = memberService.saveMember(member);
        return ResponseEntity.ok().body(result);
    }

    @PutMapping("/member/{id}")
    public ResponseEntity<Member> updateMember(@Valid @RequestBody Member member) {
        Member result = memberRepository.save(member);
        return ResponseEntity.ok().body(result);
    }

    @DeleteMapping("/member/{id}")
    public ResponseEntity<?> deleteMember(@PathVariable Long id){
        memberRepository.deleteById(id);
        return ResponseEntity.ok().build();
    }

}

可以看到我們是以@Autowired的方式, 注入MemberService, 讓Spring幫我們管理

現在我們增刪查改功能全都有了, 目前為止都是用H2 Database

下一章正式進入MySQL Database

Day 15 - MySQL 手動建立Schema與Table


上一篇
Day 13 - 什麼是IOC控制反轉? 什麼是DI依賴注入?
下一篇
Day 15 - MySQL 手動建立Schema與Table
系列文
Spring Boot and React - 前後端 30 天分手日記30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

1
obelisk0114
iT邦新手 5 級 ‧ 2019-12-07 09:28:30

不是用 service 來操作 Dao 層嗎 ? 大大怎麼只把 新增 放到 service 裡面,其他還是放 controller;不將 CRUD 都放在 service ?

Aiden iT邦新手 5 級 ‧ 2019-12-11 14:37:11 檢舉

以往我們都會有Controller -> Service -> Dao, Service層主要放business logic,
但隨著前後端分離, 可以看到有些API僅需傳遞資料, 已無任何商業邏輯, Controller也不再負責導頁, 這種情況下是否還需要多過一層Service?
目前是看到兩種寫法都有, 有人認為不需要多過一層, 有人認為全部放Service層好管理, 這取決於你專案的規範與大小,
小型輕量的專案可以省略, 但若是多人大型專案, 則需要統一規範與寫法。

Kuma iT邦新手 3 級 ‧ 2021-08-09 11:25:04 檢舉

這還是得看這個動作是「讀」還是「寫」。如果是「寫」,那就會牽扯到系統狀態的改變,需要請出 service 來做流程管理,entity 來做核心邏輯實現,最後 repository 或 dao 來做資料持久化。

如果在「寫」的過程中,感覺特別簡單,也許是運氣很好,邏輯就真的這麼簡單,也有可能是設計時沒有把「商業邏輯」帶進來,只是單純在做CURD而已。如果是後者,那也許可以考慮改用更能表現商業邏輯的街口設計。

如果是「讀」,就無所謂,反正不會動到系統狀態,就不用啟動領域物件來幫忙了,儘管在最外層讀了資料吐回去便是。

當然以上是小弟個人觀點啦 :)

我要留言

立即登入留言